This invention relates to network transport driver interfacing.
Referring to FIG. 1, in a typical computer network 10, a network communication medium (e.g., cabling) 12 carries information among computers attached to the medium, e.g., computers 14a, 14b, and 14c. The physical connection of each computer to the medium is made via a network interface card 16 which plugs into the motherboard of the computer. The computer includes the usual monitor, keyboard, mouse, CPU, memory, and disk storage (not shown) as well as software 18.
The software includes an operating system 20 (e.g., DOS, UNIX, DOS/Windows, or VMS, which manages the basic operation of the computer), portions 22 of a distributed network operating system, and at least one application 24.
Portions 22 of the distributed network operating system (e.g., Netware, LAN Manager, Pathworks, or Vines) cooperate with other portions of the network operating system located in other computers on the network to provide network services which enable the computers to cooperate with one another via the network medium. In addition to providing basic network communication services for applications, the network operating system may provide additional services such as implementation of remote procedure calls (RPCs) and network management functions.
An application 24 (e.g., a user application or a protocol engine such as KERMIT) communicates with the network operating system via an application interface 26. Data link software 28 controls, and communicates on the network via, the network interface card. A transport stack/driver 30 sits between the application interface and the data link.
The delivery of information on the network medium must comply with defined protocols which typically have several levels. Each transport stack/driver is typically designed to comply with a particular protocol, for example, TCP/IP, Serial Comm, CTERM, TELnet, or DECnet.
A variety of approaches have been taken in implementing application interfaces as part of network operating systems. They include socket interfaces, XTI, BSD Socket, TLI, and Microsoft's Transport Driver Interface (TDI), which is used for kernel level applications, for example for a redirector.
In the socket interface approach (e.g., Berkeley Sockets described in 4.3 BSD, available from the Regents of the University of California) when an application needs to read from or write to a remote node on the network, it opens a socket. The socket is like a virtual circuit between the local and remote computers (also called nodes). A socket is given a unique identifying number and may be closed when no longer needed. Once the socket is opened, the local node may perform read and write operations via the socket using the unique identifying number. When a read or write operation is initiated, the local node generally cannot proceed with its own further operations until it receives a confirmation that the read or write operation has been executed at the remote node. Thus the reads and writes (or other calls) are said to be performed synchronously and in a locally polled manner.
For an application to be able to make use of a transport stack/driver for a particular network protocol, the application (or an associated application interface) must be designed to communicate properly with the transport stack/driver. Thus, for example, an application that is designed to implement a KERMIT communication protocol may be written to interface correctly with a TCP/IP transport stack/driver offered by a particular vendor. The application (or the associated application interface) would have to be modified or rewritten if it were to be used with a different, say, DECnet transport stack/driver. A similar need for modification or rewriting would arise if the transport stack/driver were to be used with other than the operating system for which it was designed.
Another socket interface, WinSock, contemplates porting from UNIX to a Windows platform and between Windows environments; it supports a TCP/IP transport stack/driver. WinSock Version 1.0 provides for use of the Windows API in conjunction with the Internet Protocol Suite (IPS, also called TCP/IP). WinSock permits loading of vectors (jump addresses) of TCP/IP stacks of different vendors.